home *** CD-ROM | disk | FTP | other *** search
/ Chip 2007 January, February, March & April / Chip-Cover-CD-2007-02.iso / Pakiet bezpieczenstwa / mini Pentoo LiveCD 2006.1 / mpentoo-2006.1.iso / livecd.squashfs / usr / lib / metasploit / src / impurity / README.original < prev    next >
Encoding:
Text File  |  2006-06-30  |  5.2 KB  |  107 lines
  1.     Impurity-1.0
  2.     by Alexander E. Cuttergo <cuttergo@gmx.net>
  3.     
  4.     Concept
  5.     Impurity is a set of scripts which make it easy to produce a
  6. shellcode ("first stage") which is able to download over the net an 
  7. executable ELF file ("second stage") and execute it without writing it to
  8. the disk first. The first stage shellcode itself is almost constant (except 
  9. for one parameter, the executable length) and very short - 46 bytes. Using 
  10. this approach, one does not waste hours composing and debugging a complex 
  11. shellcode - just write a .c program, run impurity (which creates the second
  12. stage ELF binary) and you are all set.
  13.     Impurity is mostly useful when exploiting a daemon which runs
  14. chrooted and with dropped privileges; in such case one cannot simply execute
  15. /bin/sh. Compare it with MOSDEF and InlineEgg.
  16.     Currently impurity is implemented for Linux/i386 only; however, 
  17. porting to other OS/architectures should be trivial, provided they use ELF 
  18. standard.
  19.  
  20.     License
  21.     GPL v2
  22.  
  23.     Theory of operation
  24.     In order to be able to execute an ELF binary easily, we will have to
  25. compile it (more precisely, link it) in a special way. 
  26. 1) In order to not be troubled by shared libraries, we will link the binary
  27. statically.
  28. 2) An usual executable text segment is mapped at 0x8048000. In our case,
  29. this area is occupied by the text segment of an overflown binary. We could
  30. unmap() it, but this would make our shellcode unnecessarily large. The
  31. solution - use a linker script which will place the text segment starting at
  32. different address. We will use 0xbfff1000 - it is within the stack, so all
  33. we need to allocate memory for our executable is to do 
  34. "movl $0xbfff1000, %esp". This also means we will need an executable stack -
  35. this should not be a problem usually. Enhancing shellcode in a way which
  36. allocates memory for our ELF by mmap(...,PROT_EXEC,...) is left as an
  37. excercise for a reader.
  38. Moreover, in order to consequently simplify our first stage shellcode,
  39. command line arguments and environment are not set, dereferencing them will
  40. cause a SIGSEGV most likely. It is easily fixable in the second stage itself
  41. (see tracepath.c example).
  42. 3) In a normal executable, the text and data segments are in disjoint memory
  43. areas, with different permissions. This again complicates the loading
  44. process. To avoid it, we will link our ELF executable as impure executable
  45. (ld -N).
  46. 4) Binaries linked statically with recent glibc are large. This is usually
  47. not a problem - during the bruteforcing stage of an exploit, we do not need
  48. to send the binary at all to determine whether the correct offset has been
  49. found. Anyway, "diet libc" is recommended - small programs linked with diet
  50. libc are usually in 2k-30k size range. The provided shellcode (bootcode.S)
  51. uses an unsigned short to store the executable length, thus limiting the
  52. ELF binary to 64k (bla bla excercise for a reader bla).
  53. 5) The first stage shellcode downloads the second stage ELF binary from file
  54. descriptor 0. It should not be difficult to add code which utilizes "find
  55. socket shellcode", or just creates appropriate socket itself. Excercise,
  56. reader, make bucks by selling this enhancement, bla.
  57.  
  58. Having 1-5 in mind, executing an ELF is really simple - just read
  59. appropriate number of bytes from fd 0 into memory starting at 0xbfff1000,
  60. and then jump to 0xbfff1074, where the entry point should be. Execve()
  61. demystified ;)
  62.  
  63.     Provided code
  64. bootcode.S - first stage shellcode
  65. bootstrap.c - trivial stub which emits to stdout asm from bootcode.S,
  66.     adjusting file length u16 in its body
  67. filesize.c - a helper which prints the file size to stdout
  68. script-ld-impure-into-stack - a proper ld script
  69. tracepath.c - a sample second stage. It is almost a verbatim copy of
  70.     tracepath.c from iputils; the only changes are a few lines to
  71.     prepare a command line and environment.
  72. shelix.c - a sample program, vulnerable to a buffer overflow. It does
  73. chroot(/var/empty) and setuid(12345), so we cannot break out of chroot nor
  74. execute /bin/sh; also we have no writeable directory to download any
  75. executable to. As an example, we use impurity to produce a second stage 
  76. based on tracepath, hoping to learn the DMZ layout. Yes, we can use nmap (or
  77. linux_autorooter.0227) as the second stage easily.
  78.  
  79.     Running a sample code
  80. You have to install diet libc (http://www.fefe.de/dietlibc/) first.
  81. 1) Run "make"
  82. 2) Run "shelix" as root via [x]inetd or "nc -l -p shelix_port -e ./shelix"
  83. 3) "make" produces "ovdata" file, which contains buffer overflow payload and
  84. the first stage shellcode, so:
  85. $ (cat ovdata ; sleep 1; cat tracepath; cat) | nc localhost shelix_port
  86. Shelix: got token length 2
  87. Shelix: got token length 2
  88. Shelix: got token length 2
  89. Shelix: got token length 2
  90. Shelix: got token length 2
  91. Shelix: got token length 2
  92. Shelix: got token length 2
  93. Shelix: got token length 46
  94. Second stage OK. Which ipaddr should I try ?
  95. c.d.40.1            <- entered from stdin
  96.  1?: [LOCALHOST]     pmtu 1500
  97.  1:  x.y.131.57    2.127ms
  98.  2?: x.y.20.176
  99.  3?: a.b.40.5
  100.  4?: c.d.40.1
  101.      Resume: pmtu 1500 hops 4 back 4
  102.  
  103. Again, if you want to use a different second stage, all you need is to compile
  104. its sources instead of tracepath.c . If attacking a different vulnerable
  105. daemon, you will need to change the overflow payload creation ("ovdata"
  106. target in Makefile), but no need to touch any assembly.
  107.